Understand the meaning, significance and foundational components of research, including the formulation and evaluation of research problems.
Research is the systematic and rigorous pursuit of knowledge through structured inquiry. In computer science, where the pace of change is rapid and the boundary between applied and theoretical work is porous, formulating a clear research problem is the single most consequential decision a researcher makes. A poorly conceived problem compromises the validity, feasibility and contribution of the whole effort, however sophisticated the methodology that follows.
Two things in this lecture are examined most often: the topic-versus-problem distinction in Section 2.5, and the sources enumerated in Section 4. Both reward a computer-science example rather than a generic one.
The descending hierarchy in Section 3.3 — theme, topic, problem, question, objective — is the most useful diagnostic in the unit. Apply it to your own project: whichever level you stall at is the level you have not yet done the work on.
1. Learning Objectives
- Define and distinguish a problem from a research problem.
- Articulate the academic, practical and societal significance of a well-formulated research problem.
- Enumerate and critically evaluate the primary sources of research problems in computer science.
- Apply structured techniques for the identification and initial screening of research problems.
- Recognise the typical errors committed during research problem selection.
2. Key Concepts and Definitions
2.1 Problem
A problem is any situation, condition or phenomenon that exhibits a discernible gap between an existing state (what is) and a desired state (what ought to be). In everyday language a problem may be trivial, ambiguous or merely descriptive.
2.2 Research Problem
A research problem is a specific, well-articulated and researchable issue arising from a recognised gap in knowledge, theory or practice. It must be amenable to systematic investigation using scientific methods, and its investigation must contribute to the body of existing knowledge.
Formally, a research problem can be expressed as:
where R denotes the research problem, G the identified gap or deficiency, Q the research questions to be addressed, and F the feasibility constraints within which the inquiry is to be conducted.
2.3 Problem Statement and Research Question
- A problem statement is the textual and logical articulation of the research problem. It situates the problem in its disciplinary context, justifies its significance, and previews the general approach to be adopted.
- A research question is a focused interrogative that operationalises the problem statement, translating it into specific, answerable inquiries. Research questions typically address what, how, why or to what extent.
2.4 Research Topic versus Research Problem
| Aspect | Research topic | Research problem |
|---|---|---|
| Scope | Broad area of interest | Specific issue within the topic |
| Nature | Descriptive label | Investigative question |
| Formulation | Often a noun phrase | Usually an interrogative or declarative proposition |
| Investigation | Not directly investigable | Directly investigable using scientific methods |
| Example | Machine Learning in Healthcare | Mitigating demographic bias in chest X-ray classification models |
Students frequently begin their theses with topics rather than problems, which leads to vague, unfocused and ultimately unmanageable research designs. If your project can be named but not asked as a question, you still have a topic.
3. The Meaning of a Research Problem
3.1 What Kind of Thing a Research Problem Is
A research problem is not merely an inconvenience or a difficulty; it is a structured epistemic encounter with the unknown. In computer science the unknown manifests in several forms:
- A previously unstudied phenomenon — for instance emergent behaviour in large language model agents.
- An unresolved inconsistency in the literature — conflicting performance claims of competing algorithms.
- A practical constraint that lacks a satisfactory solution — latency in real-time edge AI inference.
- A theoretical proposition awaiting empirical verification.
The research problem occupies the ontological core of any research endeavour: it defines what is to be known and constrains how that knowing is to be pursued.
3.2 Components of a Well-Formulated Problem
- Problem domain identification — the broad subject area in which the problem resides (natural language processing, distributed systems, software engineering).
- Gap specification — a precise articulation of what is missing, unresolved or contradictory in current knowledge.
- Contextualisation — the situational, technological or societal context that renders the problem relevant.
- Population or subject definition — the entities (software systems, users, algorithms, datasets) under investigation.
- Variable identification — the key constructs whose relationships or behaviours are to be examined.
- Preliminary boundaries — the scope constraints delineating what is included and excluded.
3.3 The Hierarchy of Inquiry
- Theme: deep learning for medical image analysis.
- Topic: explainability of diagnostic models.
- Problem: the lack of clinically interpretable explanations for transformer-based radiology models.
- Question: how do post-hoc explanation techniques compare in conveying clinically meaningful information to radiologists?
- Objective: to evaluate three explanation techniques across 200 chest X-ray predictions.
This descending hierarchy is a powerful diagnostic for assessing the maturity of any research formulation. The level at which you stall is the level at which the thinking has not yet been done.
4. Significance of the Research Problem
The research problem is the fulcrum on which the entire project balances. Its significance can be enumerated across four dimensions.
4.1 Methodological Significance
The choice of problem dictates the choice of methodology. A problem seeking causal explanation demands experimental or quasi-experimental design; one seeking in-depth understanding of user experience demands qualitative inquiry; one seeking measurable improvement in system performance demands benchmark-driven evaluation. An ill-defined problem forces the researcher into inappropriate methodologies, producing results that are technically valid but practically irrelevant.
4.2 Theoretical Significance
A well-formulated problem contributes to theory construction, refinement or extension. In computing this may take the form of new algorithms, complexity bounds, formal models or architectural frameworks. Without a strong problem foundation, theoretical contributions tend to be incremental, fragmented or ad hoc.
4.3 Practical and Societal Significance
In an applied discipline, problems are often judged by practical relevance. A problem addressing an industry pain point (reducing false positives in fraud detection), a societal challenge (accessibility of digital interfaces for persons with disabilities) or an environmental concern (energy-efficient training of deep learning models) carries tangible impact.
4.4 Personal and Academic Significance
For the individual researcher, the problem shapes the entire scholarly trajectory. A well-chosen problem sustains motivation through the inevitable setbacks of empirical work, opens pathways for publication, and forms the basis of doctoral or postdoctoral work.
- Methodological mismatch — applying inappropriate instruments or techniques.
- Scope creep — continuous expansion that renders the project unfinishable.
- Invalid conclusions — inferences the data cannot support, because the question was poorly framed.
- Wasted resources — months or years spent on questions the literature has already answered.
- Publication rejection — manuscripts are routinely desk-rejected for vagueness of problem.
5. Sources of Research Problems
Research problems in computer science originate from a remarkably diverse set of sources. A mature researcher cultivates habits of attention across several channels.
5.1 Primary Sources
Those encountered directly through the researcher's own engagement with the field.
- Personal experience and practice. Practitioners who have spent years in development, system administration or data engineering develop an intuitive sense of recurring inefficiencies and unmet needs. A developer who has repeatedly struggled to debug microservices may formulate a problem on automated root-cause analysis.
- Direct observation. Watching how users interact with technology, how developers collaborate, or how systems fail in production surfaces problems invisible from the theoretical level.
- Industrial experience and internships. Internships, capstone projects and industry collaborations expose students to practical constraints not addressed in the academic literature.
5.2 Secondary Sources
Those accessed through the documented work of others.
- Academic literature — the most disciplined source. Journal articles, conference proceedings and reviews routinely identify gaps in the form of “future work”, “limitation”, “unresolved issue” and “open question”. A systematic scan of top-tier venues — NeurIPS, ICSE, SIGCOMM, CCS, IEEE S&P — reveals patterns of unresolved questions that aggregate into a coherent problem.
- Theses and dissertations — these conclude with explicit suggestions for further research, valuable because they have already passed peer scrutiny.
- Books and monographs — authoritative texts articulate the foundational problems of a sub-discipline and trace their evolution (Cormen et al. on algorithms, Tanenbaum and Van Steen on distributed systems, Sommerville on software engineering).
- Patents and industrial publications — patents disclose novel solutions and, by implication, the problems they solve. Industrial white papers from Google, Microsoft, IBM and Meta often articulate research problems years before they appear in academic venues.
- Funding agency calls — calls from DST, SERB and MeitY in India, or NSF, DARPA and the ERC internationally, articulate priorities and identify problems of strategic importance.
- Standards and regulatory documents — ISO, IEEE, NIST and similar bodies identify technical problems requiring resolution for interoperability, security or performance.
5.3 Tertiary Sources
- Discussions with peers and mentors. Supervisors and senior researchers hold contextual knowledge that points to promising problems.
- Conferences, workshops and symposia. Live discussion surfaces disagreements and unexplored intersections; the questions raised after a presentation are particularly good indicators of unresolved issues.
- Online communities. Stack Overflow, ResearchGate, arXiv comment threads, GitHub issue trackers and specialised mailing lists reveal recurring pain points.
5.4 Sources Particular to Computer Science
| Source type | Example | Typical problem type |
|---|---|---|
| Open-source issue trackers | GitHub issues on TensorFlow | Reproducibility, performance bugs |
| Benchmark leaderboards | Papers With Code | Performance gaps in specific tasks |
| Kaggle competitions | Past competition problems | Real-world data science challenges |
| Industry tech blogs | Google AI Blog, Meta Research | Emerging research directions |
| Government reports | AI safety reports | Sociotechnical problems |
| CVE databases | Common Vulnerabilities and Exposures | Cybersecurity research gaps |
6. Identification of the Research Problem
Identification differs from selection: identification surfaces candidate problems from the broader landscape, whereas selection evaluates them against criteria (the subject of Lectures 2 and 3).
6.1 The Five-Phase Identification Process
- Broad familiarisation. Immerse in the domain through a survey of recent literature, textbooks and proceedings, developing a working mental map of its contours.
- Deliberate gap search. Search for “future work”, “limitation” and “open challenge” in recent reviews; examine reference lists of seminal works for threads that have remained dormant; compare competing approaches to identify unresolved trade-offs.
- Question articulation. For each candidate gap, write a provisional research question. A useful heuristic: attempt it in a single declarative sentence. If that proves impossible, the question is not yet mature.
- Preliminary feasibility check. Check availability of data, instruments, expertise and time. Problems that fail are set aside or deferred.
- Refinement and crystallisation. Refine the survivors through iterative writing, peer discussion and supervisor consultation until a single, well-articulated problem emerges.
6.2 Techniques for Problem Identification
- Literature-driven identification — the most common technique: a systematic or scoping review, documented using PRISMA, synthesised into a conceptual map that visualises the structure of knowledge and its gaps.
- Curiosity-driven identification — less structured but often more creative. The researcher keeps a research journal of observations, questions and intuitions over weeks or months; patterns that emerge frequently crystallise into problems.
- The Delphi technique — a structured communication method in which a panel of experts answers questionnaires over multiple rounds. Anonymity reduces conformity pressure and surfaces non-obvious problems; particularly useful at disciplinary intersections.
- Brainstorming and focus groups — used less often in computing, but valuable in human-centred computing, HCI and educational technology.
- Problem tree analysis — borrowed from development research: identify the focal issue, then enumerate its causes (roots) and effects (branches). The problem may emerge from prioritising one of these.
- Concept mapping — visual representation of relationships among concepts. Maps frequently reveal clusters of densely interconnected concepts separated by sparse connections, and the sparse connections often indicate research opportunities.
6.3 Natural versus Artifactual Problems
- Natural problems — encountered in the wild, typically through industry collaboration.
- Artifactual problems — constructed for the purpose of experimentation, typically in controlled settings.
Each type has implications for the external validity of the resulting research. Researchers should consciously identify which they are pursuing and structure the methodology accordingly.
7. Illustrative Case Studies
Source: published literature on deep learning for radiology, supplemented by clinical observation during a hospital internship.
Gap: models achieve high diagnostic accuracy but produce outputs radiologists find difficult to interpret, limiting clinical adoption.
Refined problem: “How do post-hoc explanation methods (Grad-CAM, LIME, SHAP) compare in supporting diagnostic reasoning by radiologists using transformer-based chest X-ray classifiers?”
Source: industry white papers and personal observation during a research internship.
Gap: training consumes substantial energy, but the contribution of individual architectural choices is poorly characterised.
Refined problem: “What is the relative contribution of attention mechanism variants to the energy consumption of transformer training, and how does this interact with model size?”
Source: industry experience combined with surveys of the software engineering literature.
Gap: traditional technical-debt frameworks do not capture ML-specific debts — data dependencies, model staleness, feedback loops.
Refined problem: “How can existing technical debt taxonomies be extended to capture ML-specific debt in production systems, and what evidence supports the prevalence of each category?”
8. Common Errors in Selection: A Preview
A detailed treatment belongs to Lectures 2 and 3, but preliminary awareness is valuable. Researchers commonly select a problem that is:
- too broad to be investigated within the available resources;
- already conclusively addressed in the literature;
- driven primarily by technical fashion rather than genuine intellectual or practical need;
- dependent on data or instruments that are inaccessible;
- insignificant — interesting to the researcher but immaterial to the field;
- infeasible for ethical, technical or logistical reasons.
9. Summary
- A research problem is a specific, researchable articulation of a gap between existing and desired knowledge — more precise and methodologically tractable than a general topic.
- Its significance is multidimensional: methodological, theoretical, practical and personal.
- Sources are diverse, spanning personal experience, observation, academic literature, industrial practice, funding calls and online communities. Computing enjoys a particularly rich ecosystem through open-source repositories, benchmark platforms and industry publications.
- Identification is a structured five-phase process — familiarisation, gap search, question articulation, feasibility assessment, refinement — assisted by systematic review, the Delphi method and concept mapping.
- A clear hierarchy descends from theme to topic to problem to question to objective, providing a diagnostic for formulation maturity.
10. Exam Preparation
- Problem versus research problem
- Research problem versus research question
- Problem statement versus problem formulation
- Primary, secondary and tertiary sources
- Systematic literature review; PRISMA
- Delphi technique; concept mapping
- Natural versus artifactual problems
10.1 Short-Answer Questions
- Differentiate between a research topic and a research problem. Illustrate with a computer science example. 3 marks
- Why is the formulation of a research problem considered the most critical step in the research process? 3 marks
- Enumerate four sources of research problems relevant to computer science and briefly explain each. 4 marks
- Explain the role of the literature review in identifying a research problem. 3 marks
- What is the Delphi technique, and how does it assist in problem identification? 3 marks
- Distinguish between natural and artifactual problems in software engineering research. 2 marks
10.2 Long-Answer Questions
- Discuss the meaning and significance of a research problem in computer science. With suitable examples, illustrate how a broad research area is progressively narrowed into a well-defined research problem. 15 marks
- Critically examine the various sources from which research problems in computer science may be identified. Which sources do you consider most reliable, and why? 10 marks
- Describe the structured process of identifying a research problem. Explain at least three techniques employed during the identification phase, with computing examples. 12 marks
- A student wishes to undertake research on “artificial intelligence in healthcare”. Guide the student through the formulation of a well-defined research problem, citing appropriate sources and techniques. 15 marks
10.3 Applied Exercise and Reflective Prompt
Select one theme: generative AI for software engineering; blockchain-based identity management; quantum-resistant cryptographic algorithms; edge AI for autonomous systems; or privacy-preserving machine learning. Within one week, submit a maximum of 1,500 words that:
- identifies at least three candidate research problems within the theme, citing the source from which each was identified;
- refines one of them into a single, well-articulated problem statement;
- justifies its significance across academic, practical and societal dimensions;
- gives a preliminary feasibility assessment with respect to data, instrumentation and time.
Before the next lecture, keep a research journal for one week recording every instance in which you encounter a difficulty, limitation or unresolved question in your daily academic or computational work. Bring it to the next session; it becomes the basis of the first classroom exercise in problem identification.
11. Reading and References
- Creswell, J. W., & Creswell, J. D. (2018). Research Design: Qualitative, Quantitative, and Mixed Methods Approaches (5th ed.). SAGE.
- Kothari, C. R. (2004). Research Methodology: Methods and Techniques (2nd ed.). New Age International.
- Kumar, R. (2014). Research Methodology: A Step-by-Step Guide for Beginners (4th ed.). SAGE.
- Sekaran, U., & Bougie, R. (2016). Research Methods for Business (7th ed.). Wiley.
- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in Software Engineering. Springer.